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INTRODUCTION 

The floppy disk is a marvelous and yet mysterious media for mass storage 
of data. Indeed, to understand exactly how a bit of data is stored and 
retrieved from the surface of the disk requires a good knowledge of physics. 
However, to learn about the data structures found on a disk requires no 
higher mathematics than hexadecimal arithmetic. The manual supplied with 
the computer usually does an adequate job of supplying all the technical 
details, but wouldn't it sinfc in better if the actual data on the media were 
viewed while it is being described? The DISKSCAN program is used to 
demonstrate the disk data structures as they are being described. Follow the 
instructions under GETTING STARTED in the DISKSCAN USER'S GUIDE to run 
DISKSCAN. Once the program has started, remove the D I SKSCAN diskette 
and insert some other diskette that has been backed up. Use the "R" (read 
sector) function whenever you are requested to view a particular sector- 
on disk. Whenever you are requested to change the display format from hex to 
character, or vice versa, use the “T” (toggle display format) function. 


The Disk Media 



The first d i sk structure to be aw a r e of is the sect or , wh i c h on an y 
i p u ter system consists of a group of contiguous bits recorded at a specific 

fi a. t i on on the d i sk . The d i sk dr i v e h ar dwar e a 1 ways op erates on wh o 1 e 

sectors, that is to say, it is not possible to read or write partial 
sectors. Groups of sectors are organized into tracks forming 

concent r i c r i n q s about the center of the di sk * Fhe ATARI system di v i des the 
disk into 48 tracks with 18 sectors per track for a total of 728 sectors. Th i 
i s best v i sual i zed by tak i ng the lid off of the di sk dr i ve and watch i ng the 
read/write head move as certain sectors are addressed. On the ATARI 818 disk 
drive this is accompl i shed by removing the 4 phill ips head screws hidden under 
gummed tabs at each corner of the lid. Wh i le inside the case, a bit of 
1 ubr i cat i on on the 2 cyl i ndr i cal gu i de rai 1 s support i ng the head wi I 1 make the 
dr i ve 1 ess no i sy . 


If sectors 1 through 18 are read with DISKSCAN, the head remains fixed 
on the outermost track. When sector 728 is read, the head moves in to the 
innermost track. When a disk is formatted, the head can be seen to bump 
sequentially through all 48 tracks. It is laying down the patterns on the 
ox i de surface wh i ch wi 1 1 be recogn i zed by the dr i ve hardware as the sectors. 
The sectors are all initially empty (128 bytes of 8), but at the end of the 
formatting routine, as described in the next section, the ATARI DOS records 
special data into certain sectors. The top of the drive can now be re secured. 
No more information about the hardware is needed to understand the higher 
1 e v el d i sk data struct u r e s of the sof twar e . 


Boot Sector 


| At the end of the formatting process 
r t a i n se c t or s f or sp e c i a 1 t ask s . Into 

ot strap for DOS. On power-up the ATARI 


DOS reserves and initializes 
sectors 1 through 3 is stored 
op e r a ting sy s t em re ads se c t or 


the 
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to de term i n e how many sectors to r 0 a d And where i nto rnemur ;»■ tu 1 osd them. 

After it has loaded in the specified number of sectors, DOS starts executing 

the new code at the load address + 6. Put DIbKbCAN into the hex mode and read 

sector i of any DOS disk. Byte 1 says that 3 sectors are read (sequentially) 

and bytes 2 and 3 specify a load address of $700 . k A 7 byte number ss 

always specified with the least significant byte first.) Byte 6 is the 

f j p s t i n t r u c t i on t o be executed (a $ 4 C 1 40 7 i s a JMP $714). In t h i s c ase 

the code which follows sets up to load the File Management System of DOS into 

memory. This is called the second stage of the boot. Look at the first 

sec t or of an y o the r boo t d i sk ay a i 1 ab 1 e < an y game or p r ogr am wh i c h 

loads i n from di sk on power '—up) . It mi ght be seen that the program 1 oads I n 

entirely during the first stage of the boot, i.e. byte 1 of sector i has a 

sector count which represents the entire program. For more details on 

the disk boot process, see the ATARI Operating System User's Manual. 


Vo 1 ume Tab 1 e of Con tent s 


368 


Besides the first three boot sectors, DOS sets up sectors 360 to 
as the directory of the disk. DOS uses the directory to keep track of where 
files are stored on disk and how much disk space remains. Read sector 360 of 
a DOS disk with DISKSCAN in the hex mode and view a part of the directory 
called the Volume Table of Contents (VTQC) . 


Information pertaining to the avail ability of every sector on the 
^^.k is stored in this sector. Bytes 1 and 2 specify the maximum number of 
^^er data sectors on the disk <$2C3 = 707) and bytes 3 and 4 specify the 
number of free sectors remaining on the disk <707 for an empty disk, 0 for a 
full one). Starting in bit 6 <the second to highest order bit) of byte 
$@A , each bit up through byte $63 corresponds to a sector. A i 
corresponds to a free sector wh i lea© means the sector is being used. 


When a file is stored on the disk, the bits corresponding to the sectors 
used are set to 0. When the file is erased, the bits are set back to 1. 

That is why DOS, when it deletes a file, can be heard reading the entire 
file. It is determining which sectors were being used by the file so that it 
can free them back up. Notice that bits 1, 2 and 3 (bits 6, 5 and 4 of 
byte $0A) are set to 0. These correspond to the 3 boot sectors. 

Likewise, the 9 bits starting in byte $37 are 0 because they correspond to 
the sectors of the directory. These 12 sectors are thus kept from being 
overlaid by user files. 


If the VTGC i s v i ewed on an ol der d i sk wh i ch has had many file add i t i on s 
and deletions, it may be noted that the VTOC has become quite fragmented. Any 
file added to the disk may get stored into sectors scattered about the disk. 
How DOS keeps track of files spread over multiple sectors will be discussed 
shortly. By the way, even though the operating system recognizes sector 720 
(try reading it; should be all zeroes), DOS never makes use of it. True to 
Murphy's Law, it adopted the number scheme of 0 to 719 instead of 1 to 720. 

No need to bother trying to read sector 0! 



The D i rec t or y 


Of all the disk data structures, probably the most important one to be 
acquainted with is the directory. The 8 sectors following the VTGC (361-368) 
contain a list of all the files on the disk along with their size, starting 
sector and status. Put DISKSCAN into character mode and read sector 361 of a 


DOS disk that has several files on it. It can be seen that the name of the 
first file starts in byte £65 and the extension ( i f any.) starts in byte $6D. 

If any of the 11 character posi tions of the f i 1 espec are unused, i t contains a 
blank. Notice that the filenames start every 16 bytes, allowing 8 directory 
entries per 128 byte sector. Thus, the maximum number of entries for the 8 
sectors of the directory is 64. 


Now put DISKSCAN in hex mode and read sector 361. The first byte of 
each 16 byte entry contains the status of the file. For a normal file that 
byte is $-42, unless it is locked, in which case it has a status of $62. A 
deleted file has a status of $80 . An anomal y occurs whenever a f i 1 e is 
opened for output (from BASIC, perhaps) but is not closed before the comp uter- 
is powered down or glitched. Since the status of an open file is $4 6, DOS wi 1 1 
ne i ther recognize the entry as 11 in use" nor “deleted 15 « Even the sectors which 
may have been wr i tten out will not real 1 y exist on disk because the OTOC 
is not updated until the file is closed. The only harm done is that 
this bogus entry will take up space in the directory until the disk is 
reformatted. (One other solution would be to change the $43 to an $80 using 
DISKSCAN; refer to the change sector function, "C" , in the DISKSCAN USER’S 
GUIDE.) The second and third bytes of each entry contain the size in sectors 
of the file (low order byte first) while the fourth and fifth bytes 
specify the first sector of the file, DOS only needs to know the first sector 
of a file because each sector points to the next sector of the file in 
process called “linking". 

Linking 


a 



At this point it would be best to explain how DOS forms a data file on 
disk. First, the user must open an I/O channel for output to the disk, perhaps 
with the BASIC " OPEN" command. DOS responds by creating an entry in the 
directory with the specified filename and a status of $43. DOS reads the 
CHTOC into memory and searches the disk map for the first free sector. If a 
free sector is found, it's number is used as the starting sector in the 
directory entry. Now, when the user begins to output data via this I/O 
channel, perhaps with the BASIC "PUT" command, DOS waits until it has 
collected 125 bytes of user data in a buffer. Then DOS adds 3 special bytes 
of it's own and outputs the sector to the disk. I call these 3 bytes the 
" sec tor 1 i nk " . 


The sector link, bytes 125 to 127 of the sector, contains 3 pieces of 
i n f or ma t i on . The hi gh or de r 6 bit s of by t e 125 c on t a i n a n umbe r wh i c h 
represents the position of the file's entry within the directory (6 to 63). 

E>OS uses this number to check the integrity of the file. If ever this 
number should fail to match the position of the file's directory entry, 

DOS generates an error. The low order two bits of byte 125 and all of byte 
126 form a pointer to the next sector of the file. A pointer is the address 
of a record in the computer's memory or, in this case, the address of a 
record on disk, the sector number. The next sector of the file is determined 
by scanning the bit map of the UTOC for the next free sector, which may or may 
not be the next sequential sector of the disk. Thanks to the link pointers, 
sectors of a file need not be contiguous sectors on the disk. The 
byte of the sector link (byte 127 of the sector) contains the number of 
bytes used within the sector. This byte will always be $7D (125) except 
f or the last se c t or of a file, wh ich will P r obab 1 y be on 1 y p ar t i a 1 1 y filled. 
DOS writes out this partial sector only when the user closes the file, 
perhaps with the BASIC "CLOSE" command. 


When an output disk file is closed, DOS writes the newly updated WTQC back 
out to sector 368. It then updates the file's directory entry by changing the 
status to ‘£42 and filling in the file size (bytes 1 and 2) with the number of 
sectors used by the file. This completes the process of creating a 
file on disk. Now, when DOS is requested to read a file from disk, it 
finds the directory entry of the specified file to determine the start 
sector. Then, following the link pointers, it reads the file sector by- 
sector until EOF (end of file) is reached, indicated by a link pointer of 8. 


Eq u i p p e d w i t h a bas i c u n de r s t an ding of h ow a f i 1 e i s s t or e d on d i sk , try 
looking at a file with D I SKSCAN . In character mode, first locate the name 
of the desired file in the directory (sectors 361-368). Then put D I SKSCAN 
in hex mode and look at the fourth and fifth byte of the entry to determine 
the start sector . For example, if these two bytes were "IF 81”, type 
,, $i8F H in response to “Sector #?" to read the first sector of the file. 

Observe the last three bytes of the sector and verify that the high order 6 
bits of byte 125 correspond to the directory entry position and that byte 
127 is the number of bytes used (probably $7D) . Then determine the 
next sector of the file from the low order 2 bits of byte 125 and byte 126. 

For example, if bytes 125 and 126 are ,J 1 D 28" then the next sector of the 
file is $128 and the file is the eighth entry of the directory (the first entry 
being entry 8). If the file is not too long, it would be instructive to follow 
the sector links to EOF. Once the ability of finding a file on disk and 

• 11 owing the sector links is mastered, all that remains is to become familiar 
*t h the 3 types of files used by DOS. (NOTE: D I SKSCAN will automatically 
follow the sector links of a file if it is in linked mode; refer to the 
DI SKSCAN USER'S GUIDE.) 


File Types 

The first type of file is not a true file, per se , because there is no 
entry in the directory for it. This file type includes the boot record and 
the directory itself. And since the sectors which make up these files are 
not linked but, instead, are related to each other sequentially, I call these 
records "sequentially linked files". When examining a sector of the boot 
record or directory, merely increase the sector number by I to get to the 
next sector of the record. 


An example of the second type of file is that which is created with the 
BASIC "LIST" or "SAWE" command. This file consists of ASCII characters which 
either represent straight text, as in a LISTed file, or a sort of condensed 
text, as in a token i zed or SAW Ed file. Except when viewing the sector links, 
the character mode of D I SKSCAN is best suited for examining this type of file. 
At this point it would be instructive to locate in the directory of a DOS 
disk a file created with the BASIC "LIST" command. Upon determining the 
start sector, observe the file in the character mode. The BASIC program can 
be easily recognized. It may be noted that the carriage return-line feed 
character (CRLF) is displayed in it's ATASCII representation (an inverse 

« ape character) instead of executed. Now observe a file that consists of a 
gram that was SAW Ed from BASIC. Since the text has been token i zed the 
igram is harder to recognize. However, certain parts of the program 
are not altered during the token izat ion process, notably text following REM and 
PRINT statements. Now, having investigated ASCII files, it is time to 
discuss the last file type, the "binary load" file. 


The fa i nary load file is pr imar i 1 y used to load 650 k! machine code i n to 
memory for execut i on « However , its format i s so general that it can fae 
used just as easily to load any type of data, including ASCII text. Locate a 


DO 


6 • 


game or other program which is run wi th the BINARY LOAD option of 
Alternatively, create a binary load file fay saving any part of memory 
(except ROM > w i t h the B I NARY SAVE op t i on . Now observe the first sect or 
of the file wit h D I SKSCAN in the he x mode . Fir s t , n o t i c e that all bin ar y 
load files start with 2 bytes of $FF . The next four bytes are the start and 
end addresses, respectively, where the data to fol low will fae loaded into 
memory . If these four fa y tes were 11 8 0 A 8 F F B F 11 then the data would fae 1 o a d e d 
fae twe e n the a d d r esse s of $A8 8 8 an d $BFFF . I call the se f ou r by t e s a 1 oad 
v ect or . After DOS h as 1 oade dine n ou gh fay tes t o sa t i sf y the 1 oad v e c t or , i t 
assumes, unless EOF is reached, that the next four bytes specify another 
load vector. DOS will continue inputting the file at this new address. 


Up on c omp 1 e t i on of a B I NARY LOAD , c on t r o 1 will n or ma 1 1 y fae p asse d bac k t o 
the DOS menu. However, DOS can be forced to pass control to any address 
in memory fay storing that 2 byte address at location T-2EQ . To store the 
2 bytes, it is necessary to specify another load vector as part of the 
file. If, for example, i t were desired to execute the program loaded in at 
A 8 8 0 , the following load vector would fae part of the file: E8 82 E 1 82 88 A0 . 
I call this specialized load vector an autorun vector. It achieves the same 
result as the RUN AT ADDRESS option of DOS. Try to find the autorun vector in 
the file being viewed. Although it could fae at the beginning, it is most 
kely located at the very end of the file. 




Cone 1 us i on 


Anyone who has made it to the end of this tutorial and has successfully 
p e r f or me d the exerc i se s p r e se n ted here sh ou 1 d c on si d e r t h emse 1 v e s prof i c i en t 

on the subject of ATARI disk data structures. I hope this tutorial has 
been useful to those wishing to gain a perspective about how data is stored on 
disk. At the very least it should have taken some of the mystery out of 
work i ng with th i s popu 1 ar dev ice. 


